home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 16762 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  5.2 KB
  1. Path: wholder2.cts.com!user
  2. From: dbell@shvn.com (Doug Bell)
  3. Newsgroups: comp.lang.java,comp.lang.c++,comp.lang.smalltalk
  4. Subject: Re: Will Java kill C++?
  5. Date: Thu, 11 Apr 1996 22:56:02 -0700
  6. Organization: FTL Games
  7. Message-ID: <dbell-1104962256020001@wholder2.cts.com>
  8. References: <31682FFE.2781E494@bbn.com> <DpJyGG.FKK@hkuxb.hku.hk> <denatale-1004960822260001@grail1506.nando.net> <dbell-1104960125190001@wholder2.cts.com> <goochb.327.000893D1@rwi.com> <dbell-1104961159050001@wholder2.cts.com> <316D8523.74D7@concentric.net>
  9. NNTP-Posting-Host: wholder2.cts.com
  10.  
  11. In article <316D8523.74D7@concentric.net>, alovejoy@concentric.net wrote:
  12.  
  13. > Would you consider VisualBasic to be a workhorse language?  Are there
  14. > or are there not many useful programs written in VisualBasic that
  15. > are widely-used?
  16.  
  17. Yes.  And yes.
  18.  
  19. > What are the properties of Smalltalk, Java, CLOS, Scheme, Sather, Python,
  20. > Obliq, ML, etc. that make them unsuitable to be workhorse languages--that 
  21. > VisualBasic does not also have?
  22.  
  23. Wow, you know about a lot more obscure languages than I do.  :)
  24.  
  25. BTW, I have not excluded Java from the work-horse language sub-class of my
  26. organization of the programming language hierarchy, and in fact think it
  27. has an excellent possibility of becoming one.  I can't speak to all of the
  28. language examples you listed, but I would define a "work-horse" language
  29. to be one which is used by a large body of people to produce useful
  30. software which is used on a regular basis.  VisualBasic, although not a
  31. personal favorite of mine, meets this definition.  I believe that in not
  32. too long, Java will also meet this definition.  C, Pascal, C++, various
  33. assembly languages, many 4th generation "languages" also qualify, as do
  34. many languages I've not listed.  I haven't seen evidence that would
  35. convince me to place the other languages in your list into this sub-class,
  36. but that could be my lack of familiarity rather than the various
  37. languages' lack of utility.
  38.  
  39. > There are valid reasons why Smalltalk (or other advanced languages) may
  40. not be 
  41. > a good choice for many projects.
  42.  
  43. And I'm sure there are also valid reasons why they *are* the language of
  44. choice for certain projects.  Just not as often as "work-horse" languages
  45. currently meet the criteria.
  46.  
  47. > But the reason a language such as Smalltalk
  48. > is not used in most cases has more to do with prejudice, ignorance, politics,
  49. > inertia and the tendency to copy what others are doing than it does with the 
  50. > technical merits of Smalltalk or the requirements of the project.
  51.  
  52. Now you're starting to sound like the guy I was originally responding to. 
  53. Why would you assume that the match between the technical merits of
  54. Smalltalk and the requirements of the project *don't* have anything to do
  55. with it not being accepted on a broader basis?
  56.  
  57. >> Let's just say that to some extent, the answers a language *does* have
  58. >> must be relative to the impact of the software which results from it.
  59. >> What other measure would you apply?
  60. > 
  61. > I would say that the impact of the software implemented in a language
  62. > is the **intersection** (NOT the **union**) of the power of the language, 
  63. > the talent of those using it, and the assignments that the language gets 
  64. > dealt by the market.  Once one tool achieves dominance, it is very difficult
  65. > for other incompatible tools to become widely used--regardless of relative
  66. > merit (e.g., Windows, x86, S360/370, gasoline, chinese ideographs, etc).
  67. > So very good tools can have relatively small impact--because they don't
  68. > get used. 
  69.  
  70. Here is the crux of the issue.  If a tool can't meet the requirements
  71. necessary to fit the demands of the market, pool of available talent, and
  72. integration with existing systems and infrastructure, then that is the
  73. fault of the tool, not the fault of the conditions under which it must be
  74. deployed.  The technical merits of the tool can only be properly judged in
  75. the environment in which it is to be deployed, not in the confines of the
  76. laboratory.
  77.  
  78. This is the issue I have with those who look down from their ivory towers
  79. on those of us building productive software *despite* the failing of the
  80. tools, the crappy OS's and all the other realities under which any system
  81. must move forward.  It's idealistic, unrealistic and unproductive to take
  82. the position that if only the everyone could become enlightened and we
  83. dumped all the legacy systems and infrastructure, then we'd be in software
  84. heaven.  It wouldn't happen, even if we could do it, because you'd have to
  85. stop the pace of innovation as well, or heaven would start to look like
  86. what we have now--flawed.
  87.  
  88. BTW, this isn't directed at you, rather at those who take a holy-than-thou
  89. attitude, which is not how I read your response.
  90.  
  91. > Example: one could use modern linguistic science to design a much better
  92. > language than English or any other natural language.  Aren't you excited
  93. > by the prospect of using such a language?  I know, you just can't wait
  94. > to learn and start using this language.  Right?
  95.  
  96. Wrong.  Your natural language doesn't meet the requirements necessary to
  97. fit the demands of the market, pool of available talent, and integration
  98. with existing systems and infrastructure, so it isn't a better tool than
  99. the existing language, despite it's technical merits.
  100.  
  101. Doug Bell
  102. dbell@shvn.com
  103.